Management of objects representing different types of resources (such as software applications or hardware devices) is a critical issue in a data processing system, especially a computer network. This problem is particular acute for resources that have a high level of complexity or are distributed across a large number of installations.
Several technologies have been proposed in recent years for implementing a resource management framework. For example, environments for managing Java-based applications have become more and more popular with the widespread growth of the Internet (such as in e-commerce infrastructures). A standard architecture for managing resources in Java-based systems is the one conforming to the Java Management Extension (JMX) specification.
In the JMX architecture, each resource is represented by one or more MBeans. An MBean is a particular Java object, which complies with pre-set rules and principles. An MBean exposes a management interface to an MBean server, which interface defines a series of functions for accessing the associated resource. In this way, the MBeans are manageable through the MBean server that provides a standard way of performing management operations on the corresponding resources (irrespective of their implementation).
A non-MBean (a Java object that does not comply with the JMX specification) cannot be managed in the JMX architecture. This is a major problem, especially when some sort of coexistence between MBeans and non-MBeans is required. For example, whenever a resource represented by a non-MBean must be integrated into the JMX architecture, a completely new interface must be designed so as to comply with the constraints of the JMX specification. Therefore, the investment in terms of human resources spent on writing and testing the non-MBeans code is substantially lost, and a long period of time is required for attaining an acceptable level of reliability. This causes delays and high costs, and strongly limits the exploitation of the JMX architecture by structures with consolidated resource management frameworks. In any case, a good knowledge of the JMX specification is required to carry out the aforementioned conversion process.
A different approach is described in WO-A-0077632. This document proposes the use of a dynamic MBean, which is a particular type of MBean having an interface defined dynamically at run-time. For each non-MBean to be managed, an instance of the dynamic MBean is created passing the non-MBean as an argument. The dynamic MBean retrieves the characteristics conforming to the JMX specification that the non-MBean exposes. These characteristics define the interface of the non-MBean, which is returned to the MBean server. In this way, the dynamic MBean wraps the non-MBean simulating an MBean view thereof. The non-MBean may then be managed through the interface exposed to the MBean server by the dynamic MBean.
The solution described above (although quite flexible) suffers severe drawbacks. Particularly, the proposed method reduces the throughput of the resource management framework, in that each access to the non-MBean must go through time-consuming operations on the dynamic MBean.
Moreover, this structure requires the complete code of the dynamic MBean to always be available at run-time; as a consequence, the complexity of the resource management framework is strongly increased.
The method disclosed in the cited document does not support relationships between the non-MBeans. In fact, in the JMX architecture any relationship must go through the MBean server; therefore, non-MBeans calling methods on different objects directly cannot be managed using the solution described above. This drawback prevents the use of notifications among the non-MBeans.